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Code Signing System And Method 

nRaSS-REPERENCE TO REIATED APPUCA-nONS 
This application claims priority from and is related to the following prior applications: 
5 "Code Signing System And Method," United States Provisional Application No. 60/234,152, 
filed September 21, 2000; "Code Signing System And Metiiod," United States Provisional 
Application No. 60/235,354, filed September 26, 2000; and "Code Signing System And 
Method," United States Provisional Application No. 60/270,663, filed Bfebruaiy 20, 2001. 

10 ^ACKGROUNP 

1. TTOT Ti OP TH E INVENTION 

This invention relates generally to the field of security protocols for software 
applications. More patticnlaTly, the invention provides a code signing system and method that is 
particularly well suited for Java™ applications for mobile communication devices, such as 
15 Personal Digital Assistants, cellular telephones, and wireless two-way cammunication devices 
(collectively refened to hereinafter as "mobile devices" or singly "devices"). 

2. DESCRIPTION OF TEIE PT ?T ATRn ART 

Security protocols involving software code signing schemes are known. Typically, such . 
20 security protocols are used to ensure the reli^ility of software applications that are downloaded 
from the Internet. In a typical software code signing scheme, a digital signature is attached to a 
software application ftat identifies the software developer. Once the software is downloaded by 
a user, the user typically must use his or her judgment to determine whether or not the software 
1 
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application is reliable, based solely on his or her knowledge of the software developer's 
reputation. This type of code signing schesme does not ensure that a software application written 
by a third party for a mobile device will properly interact with the device's native applications 
and other resources. Because typical code signing protocols ate not secure and rely solely on the 
5 judgment of the user, there is a serious risk that destructive, "'Erojan harse" type software 
applications may be downloaded and installed onto a mobile device. 

There also remains a need for netwodc operators to have a system and method to maintain 
control over which software applications are activated on mobile devices. 

There remains a further need in 2.5G and 30 networks where corporate clients or 
10 network operators would like to control the types of software on the devices issued to its 
employees. 

SUMMARY 

A code signing system and method is provided. The code signing system operates in 
13 conjunction with a software tqpplicatian having a digital signature and includes an application 
platform, an application programming interface (API), and a virtual machine. The API is 
configured to link the software application with the application platform. The virtual machine 
verifies the authenticity of the digital signature in order to control access to the API by the 
software ^plication. 

20 A code signing system for operation in conjunction with a software application having a 

digital signature, according to another embodiment of the invention comprises an application 
platform, a plurality of APIs, each configured to link the software application with a resource on 



2 
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the application platform, and a virtual machine that verifies the authenticity of the digital 
signature in order to control access to the API by the software application, wherein the virtual 
machine veatifies (he authenticity of the digital signature in order to control access to the plurality 
of APIs by the software application. 
5 According to a further embodiment of the invention, a vaethod of controlling access to 

sensitive application programming interfaces on a mobile device con^nises the steps of loading a 
software application on the mobile device that requires access to a sensitive API, determining 
whether or not the software application includes a digital signature associated with the sensitive 
AH, and if the software application does not include a digital signature associated with the 

10 sensitive API, then denying the software application access to the sensitive AH. 

In another embodiment of the invention, a method of controlling access to an application 
programming interface (API) on a mobile device by a software application created by a software 
developer comprises the steps of receiving the software application ficom the software developer, 
reviewing the software application to determine if it may access the AH, if the software 

15 application may access the API, then appending a digital signature to the software application, 
verifying Ihe authenticity of a digital signature appended to a software application, and providing 
access to the API to software applications for which the. appended digital signature is authentic. 

A method of restricting access to a sensitive API on a mobile device, according to a 
further embodiment of the invention, comprises the steps of registering one or more software 

20 developers that are trusted to design software applications which access the sensitive API, 
receiving a hash of a software application, determining if the software application was designed 
by one of the registered software developers, and if the software application was designed by one 

3 
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of the legisteied software developeis, then generating a digital signature using the hash of the 
software application, wherein the digital signature may be appended to the software application, 
and the mobile device verifies the authenticity of the digital signature in OFder to control access 
to the sensitive AH by the software application. 

5 In a still further embodiment, a method of restricting access to application programming 

interfaces on a mobile device comprises the steps of loading a software application on the mobile 
device that requires access to one or more API, determining whether or not the software 
application includes a digital signature associated with the mobile device, and if the software 
application does not include a digital signature associated with the mobile device, then denying 

10 the software application access to the one or more APIs. 

BRIEP DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a diagram illustrating a code signing protocol according to one embodiment of 
the invention; . 

IS Fig. 2 is a flow diagram of the code signmg protocol described above with reference to 

Fig.l; 

Fig. 3 is a block diagram of a code sigjiing system on a mobile device; 
Fig. 3A is a block diagram of a code signing system on a plurality of mobile devices; 
Hg. 4 is a flow diagram illustradng the operation of the code signing system described 
iO above with reference to Fig. 3 and Hg. 3A; 

Fig. 5 is a flow diagram illustrating the management of the code signing authorities 
described with reference to Hg. 3 A; and 
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Rg. 6 is a block diagram of a mobile communication device in which a code signing 
system and method may be implemented. 

DRrATT.FnnP.srigTPTTON 
5 Referring now to the drawing figures. Fig. 1 is a diagram illustrating a code signing 

protocol acccKding to one embodiment of the invention. An application developer 12 creates a 
software application 14 (application Y) for a mobile device that requires access to one or more 
sensitive AHs on the mobile device. The software application Y 14 may, for example, be a Java 
application that opiates on a Java virtual machine installed on the mobile device. An API 

10' enables the softwaie application Y to interface with an application platfoim that may include, for 
example, lesouices such as the device hardware, operating system and cote software and data 
models. In order to make function calls to or otherwise interact with such device resources, a 
software application Y must access one or more APIs. APIs can thereby effectively "bridge" a 
software application and associated device lesouices. In this desciiption and the appended 

15 claims, references to API access should be interpreted to include access of an API in such a way 
as to allow a software application Y to interact with one or more anxesponding device resources. 
Providing access to any API therefore allows a software application Y to interact with associated 
device resoutces, whea»as denying access to an API prevents the software applicatiooni Y from 
interacting with the associated resources. For example, a database API may communicate with a 

20 device file or data storage system, and access to the database API ^ould provide for interaction 
between a software application Y and the file or data storage system. A user interface (UI) API 
would communicate with controllers and/or control software for such device components as a 
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screen, a keyboard, and any other device components that provide output to a user or accept 
input from a user. In a mobile device, a radio API may also be provided as an interface to 
wireless communication resources such as a transmitter and receiver. Similarly, a cryptographic 
API may be provided to interact with a crypto module which implements crypto algorithms on a 

5 device. "Hiese are merely iUustrative examples of APIs that may be provided on a device. A 
device may include any of these example APIs, or different AHs instead of or in addition to 
those described above. 

Preferably, any API may be classified as sensitive by a mobile device manufacturer, or 
possibly by an API author, a wireless network opeialor, a device owner or operator, or some 

10 other entity that may be affected by a virus or malicious code in a device software application. 
For instance, a mobil6 device manufacturer may classify as sensitive those APIs tiiat interface 
with cryptographic routines, wireless communication functions, or piopnetary data models such 
as address book or calendar entries. To protect against unauthorized access to these sensitive 
AHs, the plication developer 12 is required to obtain one or more digital signatures from the 

15 mobile device manufacturer or other entity that classified any APIs as sensitive, or from a code 
signing authority 16 acting on behalf of the manufactuier osr other entity with an interest in 
protecting access to sensitive device APIs, and append the signature(s) to the software 
application Y 14. . 

In one embodiment, a digital signature is obtained for each sensitive API or library that 
10 includes a sensitive API to which the software application requires access. In some cases, 
multiple signatures are desirable. This would allow a service provider, company or network 
operator to restrict soma or all software applications loaded or updated onto a particular set of 



6 
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mobile devices. In this multiplc-signatiiie scenario, all APIs are testricted and locked until a 
"global" signature is verified for a software application. For example, a company may wish to 
prevent its ranployees from executing any software applications onto their devices without first 
obtaining permission from a corporate information technology (IT) or computer services 

5 department. All such corporate mobile devices may then be configured to require verification of 
at least a global signature before a software application can be executed. Access to sensitive 
device APIs and libraries, if any, could then be further lestricted, dependent upon verification of 
respective corresponding digital signatures. 

The binary executable representation of software application Y 14 may be independent of 

10 the particular type of mobile device or model of a mobile device. Software application Y 14 may 
for example be in a write-once-run-anywhere binary format such as is the case with Java 
software applications. However, it may be desirable to have a digital signature for each mobile 
device type or model, or alternatively for each mobile device platform or manufacturer. 
Therefore, software application Y 14 may be submitted to several code signing authorities if 

IS software application Y 14 targets several mobile devices. 

Software application Y 14 is sent £rom the application developer 12 to the code signing . 
authority 16. In the embodiment shown in Hg. 1, the code signing authority 16 reviews the 
software application Y 14. although as described in further detail below, it is contemplated that 
the code signing autiiority 16 may also or instead consider the identity of the application 

10 developer 12 to determine whether or not the software application Y 14 should be signed. The 
code signing authority 16 is preferably one or more representatives from the mobile device 

7 
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manufacturer, the authors of any sensitive APIs, or possibly others that have knowledge of the 
operation of the sensitive APfe to which the software application needs access. 

If the code signing authority 16 determines that software application Y 14 may access the 
sensitive AH and therefojB should be signed, then a signature (not shown) for the software 

5 application Y 14 is generated by the code signing authority 16 and appended to the software 
application Y 14. The signed software application Y 22, conqnising the software application Y 
14 and the digital signature, is then returned to the application developer 12. The distal 
signature is preferably a tag that is generated using a private signature key 18 maintained solely 
by the code signing authority 16. For example, according to one signature scheme, a hash of the 

10 software application Y 14 may be generated, using a hashing algorithm such as the Secure Hash 
Algorithm SHAl, and then used with the private signature key 18 to create the digital signature. 
In some signature schemes, the private signature key is used to encrypt a hash of information to 
be signed, such as software appUcation Y 14, whereas in other schemes, tiie private key may be 
used in other ways to generate a signature from the information to be signed or a transformed 

15 version of the information. 

The signed software application Y 22 may then be sent to a mobile device 28 or 
downloaded by the mobile device 28 over a wireless network 24. It should be understood, 
however, that a code signing protocol according to the present invention is not limitBd to 
software applications that are downloaded over a wireless network. For instance, in alternative 

20 embodiments, the signed software application Y 22 may be downloaded to a personal computer 
via a computer network and loaded to the mobile device through a serial Imk, or may be acquired 
from the application developer 12 in any other manner and loaded onto the mobile device. Once 

8 
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the signed software application Y 22 is loaded on the mobile device 28, each digital signature is 
preferably verified with a public signature key 20 before the software application Y 14 is granted 
access to a sensitive API library. Although the signed software application Y 22 is loaded onto a 
device, it should be appreciated that the software application ftat may eventually be executed on 
5 . the device is the software application Y 14. As described above, the signed software plication 
Y 22 includes the software plication Y 14 and one or more qipended digital signatures (not 
shown). When the signatures are verified, the software application Y 14 can be executed on the 
device and access any APIs for which corresponding signatures have been verified. 

The public signature key 20 corresponds to the private signature key 18 maintained by 

10 the code signing authority 16, and is preferably installed on the mobile device along with the 
sensitive APL However, the public key 10 may instead be obtained ftom a public key repository 
(not shown), using the device 28 or possibly a personal computer system, and installed on the 
device 28 as needed. According to one embodiment of a signature scheme, the mobile device 28 
calculates a hash of the software plication Y 14 in the signed software plication Y 22, using 

15 the same hashing algorithm as'the code signing authority 16, and uses the digital signature and 
the public signature key 20 to recover the hash calculated by the signing authority 16. The 
resultant locally calculated hash and the hash recovered ftom the digital signature are then 
compared, and if the hashes are the same, the signature is verified. The software qiplication Y 
14 can then be executed on the device 28 and access any sensitive APIs for which the 

20 corresponding signatiue(8) have been verified. As described above, the invention is in no way 
limited to tins particular illustrative example signature scheme. Other signature schemes, 

9 



wo 02/25409 



PCT/CAOl/01344 



including further public key signature schemes, may also be used in conjunction with the code 
signing methods and systems described herein. 

Fig. 2 is a flow diagram 30 of the code signing protocol described above with reference 
to Fig. 1. The protocol begins at step 32. At step 34, a software developer writes the software 

5 application Y for a mobile device that requires access to a sensitive API or library that exposes a 
scnative AH (API library A). As discussed above, some or all AHs on a mobile device may be 
classified as sensitive, thus requiring verification of a digital signature for access by any software 
application such as software application Y. In step 36, application Y is tested by the software 
developer, preferably using a device simulator in which the digital signature verification function 

10 has been disabled. In this manner, the software developer may debug the software application Y 
before the digital signature is acquired from the code signing authority. Once the software 
i^lication Y has been written and debugged, it is forwarded to the code signing authority in step 
38. 

In steps 40 and 42, the code signing authority reviews the software application Y to 
15 determine whether or not it should be given access to the sensitive API, and either accepts ot 
rejects tiie software plication. The code signing authority may apply a number of criteria to 
determine whether or not to grant tiie software plication access to tiie sensitive API including, 
for example, tiie size of the software application, the device resources accessed by the API, the 
perceived utility of the software application, the interaction with other software appUcations, the 
20 inclusion of a virus or other destructive code, and whether or not the developer has a contractual 
obligation or other business arrangement with the mobile device manufacturer. Rirther details of 
managing code signing authorities and developers are described below in reference to Bg. 5. 



10 
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If the code signing authority accepts the software application Y, then a digital signature, 
and picefeiably a signature identification, are appended to the software application Y in step 46. 
As described above, the digital signature may be generated by using a hash of the software 
application Y and a private signature key 18. The signature identification is described below 
5 with reference to Hgs. 3 and 4. Once the digital signature and signatuxe identification are 
appended to the software application Y to generate a signed software application, the signed 
software application Y is returned to the software developer in step 48. The software developer 
may then license the signed software application Y to be loaded onto a mobile device (step SO). 
If the code signing autiiority rejects the software application Y, however, then a rejection 

10 notification is preferably sent to the software developer (step 44), and the software application Y 
will be unable to access any API(s) associated with the signature. 

In an alternative embodiment, the software developer may provi<te the code signing 
authority with only a hash of the software application Y, or provide the software application Y in 
some type of abridged format If the software application Y is a Java application, tiien the device 

15 independent binary *.class files may be used in tiie hashing operation, although device dependent 
files such as *.cod files used by the assi^ee of the present application may instead be used in 
hashing or other digital signature operations when software (plications are intended for 
(^esration on particular devices or device types. By providing only a hash or abridged version of 
the scftware application Y, the software developer may have the software application Y signed 

20 without revealing proprietary code to the code signing authority. The hash of the software 
application Y, along with tiie private signature key 18, may tiien be used by the code signing 
authority to generate the digital signature, if an otherwise abridged version of the software 
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application Y is sent to the code signing authority, then the abridged version raay similarly be 
used to generate the digital signature, provided that the abridging scheme or algorithm, Ukie a 
hashing algorithm, generates different outputs for different inputs. This ensures that every 
software application will have a different abridged version and thus a different signature that can 

5 only be verified when appended to the particular corresponding software application from which 
the abridged version was generated. Because this embodunent does not enable the code signing 
authority to thoroughly review the software application for viiuses or other destructive code, 
however, a registration process between the software developer and the code signing authority 
may also be required. For instance, the code signing authority may agree in advance to provide a 

10 tmsted software developer access to a limited set of sensitive APIs. 

In still another alternative embodiment, a software application Y may be submitted to 
more than one signing authority. Each signing authority may for example be responsible for 
signing software applications for particular sensitive APIs or APIs on a particular model of 
mobile device or set of mobile devices that supports the sensitive APIs required by a software 

15 application. A manufacturer, mobile communication netwoifc operator, service provider, or 
corporate client for example may thereby have signing authority over the use of sensitive APIs 
for their particular mobile device model(s), or the mobile devices operating on a particular 
network, subscribing to one or more particular services, or distributed to corporate employees. 
A signed software application may then inclu<te a software application and at least one appended 

20 digital signature appended from each of the signing authorities. Even though these signing 
authorities in this example would be generaimg a signature for the same software application, 

12 
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different signing and signature vedficatioii schemes may be associated with the different signing 
authorities. 

Rg. 3 is a block diagram of a code signing system 60 on a mobile device 62. The system 
60 includes a virtual machine 64, a plurality of software applications 66-70, a plurality of API 

5 libraries 72-78, and an application platform 80. The application platform 80 preferably includes 
all of the resources on.the mobile device 62 that may be accessed by the software applications 
66-70. For instance, the application platform may include device hardware 82, the mobile 
device's operating system 84, or core software and data models 86. Each API library 72-78 
pieferably includes a plurality of APIs that interface with a resource available in the application 

10 platform. For instance, one API library might include all of the APIs that interface with a 
calendar program and calendar entry data models. Another API library might include all of the 
APIs that interface with the transmission circuitry and functions of the mobile device 62. Yet 
another AH library might include all of the APIs capable of interfacing with lower-level services 
performed by the mobile device's operating system 84. In addition, the plurality of API libraries 

IS 72-78 ntiay include both libraries that expose a sensitive API 74 and 78, such as an interface to a 
cryptographic function, and libraries 72 and 76, that may be accessed without exposing sensitive 
APIs. Similarly, the plurality of software applications 66-70 may include both signed software 
applications 66 and 70 that require access to one or more sensitive APIs, and unsigned software 
s^lications such as 68. The virtual machine 64 is preferably an object oriented run-time 

JO environment such as Sun Micro System's XZME™ (Java 2 Platform, Micro Edition), which 
manages the execution of aU of tbp software applications 66-70 operating on the mobile device 
62, and links the software applications 66-70 to the various API Ubraries 72-78. 

13 
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Software application Y 70 is an example of a signed software application. Each signed 
software application preferably includes an actual softwaio application such as software 
application Y comprising fcff example software code that can be executed on the application 
platform 80, one or more signature identifications 94 and one or more corresponding digital 

S signatures 96. Prefeiably each digital signature 96 and associated signature identificatiQn 94 in a 
signed software arolication 66 or 70 corresponds to a sensitive AH library 74 or 78 to which the 
software jqjpKcation X or software appMcation Y requires access. The sensitive API library 74 or 
78 may include one or more sensitive APIs. In an alternative embodimeait, the signed software 
applications 66 and 70 may include a digital signature 96 for each sensitive API within an API 

10 library 74 or 78. The signature identifications 94 may be unique integers or some other means of 
relating a distal signature 96 to a specific API library 74 or 78, API, application platform 80, or 
model of mobile device 62, 

API library A 78 is an example of an API library that exposes a sensitive API. Each API 
library 74 and 78 including a sensitive API should preferably include a description string 88, a 

15 public signature key 20, and a signature identifier 92. The signature identifier 92 preferably 
conesponds to a signature identification 94 in a signed software application 66 or 70, and 
enables the virtual machine 64 to quickly match a digital signature 96 with an API library 74 or 
78. The public signature key 20 cdrresponds to the private signature key 18 maintained by the 
code signing authority, and is used to verify the authenticity of a digital signature 96. The 

20 description string 88 may for example be a textual message that is displayed on the mobile 
device when a si^ed software a^Iication 66 or 70 is loaded, or alteanatively when a software 
plication X or Y attempts to access a sensitive APL 

14 
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Operationally, when a signed software application 68-70, respectivdy including a 
software application X, Z, or Y, that requires access to a sensiti've API library 74 or 78 is loaded 
onto a mobile device, the virtual machine 64 searches the signed for an appended digital 
signature 96 associated with the API library 74 or 78. Preferably, the q)propriate digital 

5 signature 96 is located by the virtual machine 64 by matching the signature identifier 92 in the 
API library 74 or 78 with a signature identification 94 on ihe signed software application. If the 
signed software application includes the appropriate digital signature 96, then the virtual 
machine 64 verifies its authenticity using the public signature key 20. Then, once the 
appropriate digital signahne 96 has been located and verified, the description string 88 is 

10 preferably displayed on the mobile device before the software application X or Y is executed and 
accesses the sensitive AFL For instance, the description string 88 may display a message stating 
that "Application Y is attempting to access API library A," and thereby provide the mobile 
device user with the final control to grant or deny access to the sensitive API. 

Fig. 3A is a block diagram of a code signing system 61 on a plurality of mobile devices 

15 62E, 62F and 62G. The system 61 includes a plurality of mobile devices each of which only 
three are illustrated, mobile devices 62E, 62F and 62G. Also shown is a signed software 
application 70, including a software application Y to which two digital signatures 96E and 96F 
with corresponding signature identifications 94E and 94F have been appended. In the example 
system' 61, each pair composed of a digital signature and identification, 94E/96E and 94F/96F, 

JO corresponds to a model of mobile device 62. AH Htaiary 78, or associated platform 80. If 
signature identifications 94E and 94F correspond to different models of mobile device 62, then 
when a signed software application 70 which includes a software application Y that requires 
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access to a sensitive API library 78 is loaded onto mobile device 62E, the virtual machine 64 
searches the signed software application 70 for a digital signature 96E associated with the API 
library 78 by matching identifier 94E with signature identifier 92. Similarly, when a signed 
software application 70 including a software application Y that requires access to a sensitive AH 

5 library 78 is loaded onto a mobile device 62F, the virtual machine 64 in device 62F searches the 
signed software application 70 for a distal signature 96F associated with the API library 78. 
However, when a software application Y in a signed software application 70 that requires access 
to a sensitive API library 78 is loaded onto a mobile device model for which the application 
developer has not obtained a digital signature, device 62G in the example of Fig. 3A, die virtual 

10 machine 64 in the device 64G does not find a digital signature appended to the software 
application Y and consequently, access to the API library 78 is denied on device 62G. It should 
be appreciated from the foregoing description that a software application such as software 
application Y may have multiple device-specific, library-specific, or API-specific signatures or 
some combination of such signatures appended thereto. Similarly, different signature 

IS verification requirements may be configured for the different devices. For example, device 62E 
may require verification of both a global signature, as well as additional signatures for any 
sensitive APIs to which a software application . requires access in order for the software 
application to be executed, whcEieas device 6ZF may require v^dfication of only a global 
signature and device 62G may require verification of signatures only for its sensitive APIs. It 

20 should also be apparent that a communicatioD system may include devices (not shown) on which 
a software plication Y received as part of a signed software plication such as 70 may 
execute without any signature verification. Although a signed software application has one or 

16 
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more signatures appended theaoeto, the software application Y might possibly be executed on 
some devices without first having any of its signature(8) verified. Signing of a software 
application preferably does not interfere with its execution on devices in which digital signature 
verification is not iniplemented. 

5 Kg. 4 is a flow diagram 100 illustrating the operation of the code signing system 

described above with reference to Figs. 3 and 3A. In step 102, a softwaie application is loaded 
onto a mobile device. Once the software application is loaded, the device, preferably using a 
virtual machine, determines whether or not the software application requires access to any API 
libraries that expose a sensitive API (step 104). If not. then the software application is linlced 

10 with all of its required API libraries and executed (step 118). If the software application does 
require access to a SMisitive API, however, then the virtual machine verifies that the software 
application includes a valid digital signature associated any sensitive APIs to which access is 
required, in steps 106-116. 

In step 106, the virtual machine retrieves the public signature key 20 and signature 

15 identifier 92 firom the sensitive API library. The signature identifier 92 is then used by the 
virtual machine in step 108 to determine whether or not the software application has an appended 
digital signature 96 with a corresponding signature id^itification 94. If not, then the software 
application has not been approved for access to the sensitive API by a code signing authority, 
and the software application is preferably prevented from being executed in step 116. In 

20 alternative embodunents, a software application without a proper digital signature 96 may be 
purged fix>m the mobile device, or may be denied access to the AH library exposing the sensitive 
API but executed to the extent possible without access to the AH library. It is also contemplated 
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that a user may be prompted for an input when signature verification fails, thereby providing for 
user control of such subsequent operations as putgmg of the software application from the 
device. 

If a distal signature 96 corresponding to the sensitive API library is appended to the 

5 software application and located by the virtual machine, then the virtual machine uses the public 
key 20 to verify the authenticity of the digital sigpatuie 96 in step 110. This step may be 
perfottned, for example, by usmg the signature verification scheme described above or other 
alternative signature schemes. If the digital signature 96 is not authentic, then the software 
application is preforably either not executed, purged, or restricted from accessing the sensitive 

10 API as described above with reference to step 1 16. If the digital signature is authentic, however, 
then the description string 88 is preferably displayed in step 112, warning the mobile device user 
that the software appKcatioo requires access to a sensitive AH, and possibly prompting the user 
for authorization to execute or load the software application (step 114). When more than one 
signature is to be verified for a software application, then the steps 104-110 are preferably 

15 repeated for each signature before the uscar is prompted in step 112. If the mobile device user in 
step 114 authorizes the software application, then it may be executed and linked to the sensitive 
APIlibraryin step 118. 

Hg. 5 is a flow diagram 200 illustrating the management of the code signing authorities 
described with reference to Fig. 3A. At step 210, an application developer has developed a new 

20 software application which is intended to be executable one or more target device models or 
types. The targpt devices may include sets of devices from different manufacturers, sets of 
device models or types from the same manufacturer, or generally any sets of devices having 
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particular signature and verification lequiiements. The teim "target device" refers to any such 
set of devices having a common signature lequiiement. For example, a set of devices requiring 
verification of a device-specific global signature for execution of all software applications may 
conqnise a target device, and devices that require both a global signature and further signatures 

5 for SKisitive APIs may be part of more than one target device set. The software application may 
be written in a device independent manner by using at least one known AFI, supported on at least 
one target device with an API library. Preferably, the developed software application is intended 
to be executable on several target devices, each of which has its own at least one API library. 

At step 220, a code signing authority for one target device receives a target-signing 

10 request £rom the developer. The target signing request includes llie software application or a 
hash of the software application, a developer identifier, as well as at least one target device 
identifier which identifies the target device for which a signature is being requested. At step 230, 
the signing authority consults a developer database 235 or other records to determine whether or 
not to trust developer 220. This determination can be inade according to several criteria 

IS discussed above, such as whether or not the developer has a contractual obligation or has entered 
into some other type of business arrangement with a device manufacturer, network operator, 
service provider, or device manufacturer. If the developer is trusted, then the method proceeds at 
step 240. However, if the developer is not trusted, then the software ai^Iication is rejected (250) 
and not signed by the signing authority. Assuming the developer was trusted, at step 240 the 

20 signing authority determines if it has the target private key conesponding to tiie submitted target 
identifier by consulting a private key store such as a target private key database 245. If the target 
private key is found, then a digital signature for the software application is generated at step 260 



wo 02«5409 



PCT/CAOl/01344 



and the digital signature or a signed software application including the digital signature appended 
to the software application is returned to the developer at step 280. However, if the target private 
key is not found at step 240, then flie software application is rejected at step 270 and no digital 
signature is genaated for the software application. 
5 Advantageously, if target signing authorities follow compatihle embodiments of the 

method outlined in Fig. 5, a network of target signing authodties may be established in order to 
expediently manage code signing authorities and a developer community code signing process 
providing signed software applications foa: multiple targets with low likelihood of destructive 
code. 

10 Should any destructive or otherwise problematic code be found in a software application 

or suspected because of behavior exhibited when a software application is executeld on a device, 
then the registration or privileges of the CQtresponding applicatioii developer v^ith any or all 
signing authorities may also be suspended or revoked, since ttie digital signature provides an 
audit trail through which the developer of a problematic software application may be identified. 

15 In such an event, devices may be infooned of the revocation by being configured to periodically 
dovniload signature revocation lists, for example. If software applications for which the 
corresponding digital signatures have been revoked are running on a device, the device may then 
halt execution of any such software application and possibly purge the software application from 
its local storage. If preferred, (tevices may also be configured to re-execute digital signature 

20 verifications, for instance periodically or when a new revocation list is downloaded. 

Although a digital signature generated by a signing authority is dependent upon 
authentication of the application developer and confirmation that the application developer has 

20 
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been properly registered, the digital signature is preferably generated from a hash or otherwise 
transformed version of the software plication and is therefore application-apeciflc. This 
contrasts with known code signing schemes, in which API access is granted to any software 
applications arriving from trusted application developers or authors. Jn the code signing systems 

5 and methods described herein, AH access is granted on an s^plication-by-application basis and 
thus can be more strictly controlled or regulated. 

Hg. 6 is a block diagram of a mobile communication device in which a code signing 
system and method may be in^lemented. The mobile communication device 610 is prefeiably a 
two-way commumcatian device having at least voice and data communication capabilities. The 

10 device preferably has the capability to conununicate with other computer systems on the IhtemeL 
Depending on the functionality provided by the device, the device may be referred to as a data 
messaging device, a two-way pager, a cellular telephone with data messaging capabilities, a 
wireless Internet appliance or a data communication device (with or without telephony 
capabilities). 

IS Where the device 610 is enabled for two-way communications, the device will 

incorporate a commxinication subsystem 611, including a receiver 612, a transmitter 614, and 
associated components such as one or more, preferably embedded or internal, antenna elements 
616 and 618, local oscillates (LOs) 613, and a processing module such as a digital signal 
processor (DSP) 620. As will be apparent to those skilled in the field of communications, the 

20 particular design of the communication subsystem 611 will be dependent upon the 
communication network in which the device is intended to operate. For example, a device 610 
destined for a North American market may include a communication subsystem 611 designed to 
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operate within the Mobitex™ mobile coramunication system or DataTAC™ mobile 
communication system, whereas a device 610 intended for use in Euiope may incorporate a 
Genera] Packet Radio Service (GPRS) communication subsystem 611, 

Network access requirements will also vary depending upon the type of network 919. For 
5 example, in the Mobitex and DataTAC networks, mobile devices such as 610 are registered on 
the network using a unique identification number associated with each device. In GPRS 
networks however, netwoxk access is associated with a subscriber or user of a device 610. A 
GPRS, device therefore requires a subscriber identity module (not shown), coanmonly referred to 
as a SIM card, in order to operate on a GPRS network. Without a SIM card, a GPRS device will 

10 not be fully functional. Local or non-network communication functions (if any) may be operable, 
but the device 610 will be unable to carry out any functions involving communications over 
network 619, other than any legally required operations such as "91 1" emergency calling. 

When required network registration or activation procedures have been completed, a 
device 610 may send and receive communication signals over the network 619. Signals received 

15 by the antenna 616 through a communication network 619 are input to the receiver 612. which 
may perform such common receiver functions as signal amplification, frequency down 
conversion, filtering, channel selection and the like, and in the exaix^le system shown in Fig. 6, 
analog to digital conversion. Analog to digital conversion of a received signal allows more 
complex commuinication functions such as demodulation and decoding to be performed in. the 

20 DSP 620. In a similar manner, signals to be transmitted are processed, including modulation and 
encoding for example, by tiie DSP 620 and input to the transmitter 614 for digital to analog 
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conversion, frequency up conveision, filtering, ampUfication and transmission over the 
communication network 619 via the antenna 618. 

The DSP 620 not only processes communication signals, but also provides for receiver 
and transmitter control. For example, the gains applied to communication signals in the receiver 
5 612 and transmitter 614 may be adaptively controlled through automatic gain control algorithms 
implemented in the DSP 620. 

The device 610 preferably includes a microprocessor 638 which controls the overall 
operation of the device. Communication functions, including at least data and voice 
communications, are performed through the communication subsj^tem 611. The microprocessor 
10 638 also interacts with further device subsystems or resources such as the display 622, flash 
memory 624, random access memory (RAM) 626, auxiUaiy input/output (I/O) subsystems 628, 
serial port 630, keyboard 632, speaker 634, microphone 636, a short^rangp communications 
subsystem 640 and any other device subsystems generally designated as 642. APIs, including 
sensitive APIs requiring verification of one or more corresponding digital signatures before 
15 access is granted, may be provided on the device 610 to interface between software applications 
and any of the resources shown in Fig. 6. 

Some of the subsystems shown in Fig. 6 perform communication-related functions, 
whereas other subsystems may provide '^sidentf' or on-device functions. Notably, some 
subsystems, such as keyboard 632 and display 622 for example, may be used for both 
20 communication-relaled functions, such as entering a text message for transmission over a 
conraiunication network, and device-resident functions such as a calculator or task list 
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Operating system software used by the microprocessor 638, and possibly APIs to be 
accessed by software applications, is preferably stored in a persistent store such as flash memory 
624, which may instead be a read only memory (ROM) or similar storage element (not shown). 
Those skilled in the art will ^leciate that the operating system, specific device software 
5 applications, or parts thereof, may be temporarily loaded into a volatile store such as RAM 626. 
It is contemplated that received and transmitted communication signals may also be stored to 
JIAM626. 

The micropiocessor 638, in addition to its operating system functions, pmferably enables 
execution of software applicatioas on the device. A predetennined set of applications which 

10 control basic device operations, including at least data and voice communication applications for 
example, will normally be installed on the device 610 during manufacture. A preferred 
application that may be loaded onto the device may be a personal infonnation manager (PIM) 
application having the ability to organize and manage data items relating to the device user such 
as, but not limited to e-mail, calendar events, voice mails, appointments, and task items. 

15 Naturally, one or more memoiy stores would be available on the device to facilitate storage of 
PEM data items on the device. Such PIM application would preferably have the ability to send 
and receive data items, via the wireless netwodc. In a preferred embodiment, the PIM data items 
are seamlessly integrated, synchronized and updated, via the wireless network, with the device 
user's corresponding data items stored or associated with a host computer system thereby 

20 creating a mirrored host coinputer oa the mobile device with respect to the data items at least 
This would be especially advantageous in the case where the host computer system is the mobile 
device user's office conputer systenL Birther applications, including signed software 
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applications as described above, may also be loaded onto the device 610 through the network 
619, an auxiliary I/O subsystem 628, serial port 630, short-range cQtnmunications subsystem 640 
or any other suitable subsystem 642. The device microprocessor 638 may then verify any digital 
signatures, possibly including both "global" device signatures and API-specific signatures, 

5 appended to such a software application before the software application can be executed by the 
microprocessor 638 and/or access any associated sensitive APIs. Such flexibility in application 
installation increases tiie functioDality of the device and may provide enhanced on-device 
functions, comnnmication-related fiinctionB, or both. For example, secure communication 
applications may enable dectromc commeice functions and other such financial transactions to 

10 be perfcomed using the device 610, through a crypto API and a crypto module which implements 
crypto algorithms on the device (not shown). 

In a data communication mode, a received signal such as a text message or web page 
download will be processed by the communication subsystem 611 and input to the 
microprocessor 638, which v«ll preferably further process the received signal for output to the 

IS display 622, or alternatively to an auxiliary I/O device 628. A user of device 610 may also 
. compose data items such as email messages for example, using the keyboard 632, which is 
preferably a complete alphanumeric keyboard or telephone-type keypad, in conjunction with the 
display 622 and possibly an auxiliaty I/O device 628. Such con^osed items may then be 
transmitted over a communication network through the communication subsystem 611. 

20 For voice communications, overall operation of the device 610 is substantially similar, 

except that received signals would preferably be output to a speaker 634 and signals for 
transmission would be generated by a microphone 636. Alternative voice or audio I/O 
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subsystems such as a voice message recording subsystem may also be implemented on the 
device 610. Alfliough voice or audio signal output is preferably accomplished primarily through 
the speaker 634, the display 622 may also be used to provide an indication of the identity of a 
calling party, the duration of a voice call, or other voice call related information for exair^le. 
5 • The serial port 630 in Fig. 6 would normally be implenwnted in a prasonal digital 
assistant CPDA)-type communication device for which synchronization with a user's desktop 
computer (not shown) may be desirable, but is an optional device component Such a port 630 
would enable a user to set prefeiBnoes through an extemal device . or software application and 
would extend the capabilities of the device by providing for infonnation or softwaie downloads 

10 to the device 610 other ttim thtou^ a wireless communication network. The alternate download 
path may for example be used to load an encryption key onto the device through a direct and thus 
reliable and trusted coonectian to thereby enable secure device communication. 

A short-range communications subsystem 640 is a farther optional component which 
may provide for communication between the device 624 and different systems or devices, which 

IS need not necessarily be similar devices. For example, the subsystem 640 may include an infrared 
device and associated circuits and components or a Bluetooth™ communication module to 
provide for communication with similarly-enabled systems and devices. 

The embodiments described herein are examples of structures, systems or methods 
having elements corresponding to the elements of the invention recited in the claims. This 

20 written description may enable those skilled in the art to make and use embodiments having 
alternative elements that likewise correspond to the elements of the invention recited in the 
claims. The intaaded scope of the invention thus includes other structures, systems or methods 
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that do not differ from the literal language of the claims, and further includes other structures, 
systems or methods with msubstantial differences from the literal language of the claims. 

For example, when a software application is rejected at step 250 in the method shown in 
Fig. 5, ftie signing authority may request that the developer sign a contract or enter into a 

5 business relationship with a device manufacturer or other entity on whose behalf the signing 
authority acts. Similarly, if a software application is rejected at step 270. authority to sign the 
software application may be delegated to a different signing authority. The signing of a software 
application following ddegaiion of signing of the software applicaticoD to ttie different authority , 
can proceed substantially as shown in Hg. 5, wherein the target signing authority that received 

10 the original request from the trusted developer at step 220 requests that the software application 
be signed by tiie different signing authority on behalf of the trusted developer frop the target 
si gning authority. Once a trust relationship has been established betwerai code signing 
authorities, target private code signing keys could be shared between code signing aufliorities to 
improve performance of the method at step 240, <x a device may be configured to validate digital 

15 signatures from either of the trusted signing authorities. 

In addition, although described primarily in the context of software applications, code 
signing systems and methods according to the present invention may also be applied to other 
device-related components, including but in no way limited to, commands and associated 
command arguments, and libraries configured to interface with device resources. Such 

20 commands and libraries may be sent to mobile devices by device manufacturers, device owners, 
network operators, service providers, software application developesrs and the like. It would be 
desirable to control the execution of any command that may affect device operation, such as a 
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cominand to change a device identification code or wiieless communication network address for 
example, by requinng verification of one or more digital signatures before a command can be 
executed on a device, in accordance with the code agning systems and methods described, and 
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We claim: 

1, A code signing system for operation in conjunction with a software application having a 
digital signature, comprising: 
an application platform; 

5 an application programming interface (API) configured to link the software application 

witii the application platform; and 

a virtual machine that verifies Use airthenticity of the distal signature in onier to control 
access to the API by the software application. 

10 2. The code signing system of claim 1, wherein the virtual machine denies the software 
application access to the API if the digital signature is not autiientic. 

3. The code signing system of claim 1, wherein the virtual machine purges the software 
application if the digital signature is not authentic. 

15 

4. The code signing system of claim 1, wherein the code signing system is installed on a mobile 
device. 



5. The code signing system of claim 1, wherein the digital signature is generated by a code 
20 signing autiiority. 
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6. A code signing system for operation in conjunction with a software application having a 
digital signature, con^sing: 

an appHcation platform; 

a plurality of a^Iication progranumng intraf aces (APIs), each configured to link the 
5 software application with a resource on the application platform; and 

a virtual machine that verifies the authenticity of the digital sigoatuie in <nder to control 
access to the API by the software application, 

wherein the virtual machine verifies the authenticity of the digital signaturB in order to conttol 
access to the plurality of APIs by the software application. 

10 

7. The code signing system of claim 6, wherein the plurality of APIs are included in an API 
Hbrary. ^ 

8. The code signing system of claim 6, wherein one or more of the plurality of APIs is classified 
15 as sensitive, and wherein the virtual machine uses the digital signature to control access to the 

sensitive APIs. 

9. ' The code signing system of claim 8, for operation in conjunction with a plurality of software 
applications, wherein one or more of the plurality of software applications has a digital signature, 

20 and wherein the viitual machine verifies the authenticity of the digital signature of each of the 
one or more of the plurality of software applications in order to control access to the sensitive 
APIs by each of the plurality of software applications. 

30 
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10. The code signing system of claim 6, wherein the resource on the application platform 
comprises a wireless communication system. 

5 11. The code signing system of claim 6, wherein the resource on the application platform 
comprises a cryptographic module which implements cryptographic algorithms. 

12. The code signing system of claim 6. wherein the lesouioe on the application platform 
comprises a data store. 

10 

13. The code signing system of claim 6, wherein the resource on the application platform 
comprises a user interface (US). 

14. The code signing system of claim 1, further con^)rising: 

IS a plurality of API libraries each including a plurality of APIs, wherein the virtual 

machine controls access to the plurality of API libraries by the software application. 

15. The code signing system of claim 14, wherein one or more of the plurality of AH libraries is 
classified as sensitive, and wherein the virtual machine uses the digital signature to control 

20 access to the sensitive API libraries by the software {plication. 
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16. The code signing system of claim 15, wherein the software application includes a unique 
digital signature for each sensitive API library, 

17. The code signing system of claim 16, wherein: 

5 the software application includes a signature identification for each unique digital 

sigoatuie; 

each sensitive AFI Uhrary includes a signature identifier; and 

the virtual rnachine compaies the signature identificaticn and the signature identifier to 
match the unique digital signatures with sensitive AFI libraries. 

10 

18. The code signing system of claun 1, wherein the digital signature is generated usmg a 
private signature key, and the virtual machine uses a public signature key to verify the 
authenticity of the digital signature. 

15 19. The code signing systemofclaun 18, wherein: 

the digital signature is generated by applying the private signature key to a hash of the 
software application; and 

tiie virtual machine verifies the authenticity of the digital signature by generating a hash 
of the software application to obtain a generated hash, applying the public signature key to the 
20 digital signature to obtain a recovered hash, and comparing the generated hash with the 
recovered hash. 

32 
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20. The code signing system of claim 1. wherein the API fuither comprises: 

a description string that is displayed by the mobile device when the software plication 
attempts to access the AFL 

21. The code signing system of claim 1, wherein the application platfomi comprises an 
operating system. 

22. The code signing system of claim 1, wheiein the application platfonu comprises one or more 
core functions of a mobile device. 

23. The code signing system of claim 1, wherein the application platfonn comprises hardware 
on a mobile device. 

24. The code signing system of claim 23, wheiein the haidwats comprises a subscriber identity 
module (SIM) card. 

25. The code signing system of claim 1, wherein the software application is a Java application 
for a mobile device. 



26. The code signing system of claim 1 , wherein the API interfaces with a cryptographic routine 
on the application platfonn. 
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27. The code signing system of claim 1, wherein the AH interfaces with a proprietary data 
model on the application platfonn. 

28. The code signing system of claim 1, wherein the virtual machine is a Java virtual machine 
5 installed on a mobile device. 

29. A method of controlling access to sensitive application programming interfaces on a mobile 
device, comprising the steps of: 

loading a software application on the mobile device that requires access to a sensitive 
1 0 apphcation programming interface (AFI); 

determiQiiig whether or not the software application includes a digital signatuce 
associated with the sensitive AH; and 

if the software application does not include a digital signature associated with the 
sensitive AH, then denying the software apphcation access to the sensitive AH. 

15 

30. The method of claim 29, comprising the additional step of: 

if the software application does not include a digital signature associated with the 
sensitive API, then purging the software application from the mobile device. 

20 31. The method of claim 29, wherein the digital signature is generated by a code signing 
authority. 
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32. The method of claim 29, comprising the additional steps of: 

if the software appUcation includes a digital signature associated with the sensitive API, 
then verifying the authenticity of the digital signature; and 

if the digital signature is not authentic, then denying the software application access to 
5 the sensitive APL 

33. The method of claim 32, comprising the additional step of: 

if the digital signature is not authentic, then purging the software application from the 
mobile device. 

10 

34. The method of claim 32, wherein the digital signature is gpnerated by applying a private 
signature key to a hash of the software appUcation, and wherein the step of verifying the 
authenticity of the digital signature is performed by a method comprising the steps of: 

storing a public signature key that corresponds to the private signature key on the mobile 

15 device; 

generating a hash of the software appUcation to obtain a generated hash; 

applying the public signature key to the digital signature to obtain a recovered hash; and 

comparing the generated hash with the recovered hash. 

20 35. The method of claim 34, wherein the digital signature is gpnerated by calculating a hash of 
the software application and applying the private signature key. 
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36. The method of claim 29, comprising the additional step of: 

displaying a description string that notifies a user of the mobile device that the software 
application requires access to the sensitive API. 

5 37. The method of claim 36, comprising the additional step of: 

receiving a command ftom the user granting or denying the software application access 
to the sensitive API. 

38. A method of controlling access to an application programming interface (AH) on a mobile 
10 device by a software application cieated by a software developer, compdsing the steps of: 

receiving the software application from the software developer; 
reviewing the software application to determine if it may access the AH; 
if the software application may access the AH, then appending a digital si^ature to the 
software application; 

15 verifying the authenticity of a digital sigDature appended to a software application; and 

providing access to the AH to software applications for which the appended digital 
signature is authentic. 

39. The method of claim 38, wherein the step of reviewing the software application is performed 
20 by a code signing authority. 



36 



wo 02^25409 



PCT/CAOl/01344 



40. The method of claim 38, wherein the step of appending the digital signature to the software 
application is pcrfonned by a method comprising the steps of: 

calculating a hash of the software application; and 

applying a signature key to the hash of the software application to generate the digital 
signature. 

41. The method of claim 40, wherein the hash of the software application is calculated using the 
Secure Hash Algorithm (SHAl). 

42. The method of claim 40, wherein the step of verifying the authenticity of a digital signature 
comprises the steps of: 

providing a corresponding signature lEcy on the mobile device; 
calculating the hash of the software iqjplication on the mobile device to obtain a 
calculated hash; 

applying the costresponding signature key to the digital signature to obtain a recovered 
hash; and 

determining if the digital signature is authentic by comparing the calculated hash with the 
recovered hash. 



43. The method of claim 42, comprising the further step of, if the digital signature is not 
authentic, then denying the software application access to the API. 
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44. The method of claim 42, wherein the signature key is a private signature key and the 
corresponding signatuie key is a public signature key. 

45. A method of controlling access to a sensitive application programming interface (API) on a 
5 mobile device, comprising the steps of: 

registering one or more software developers that aie trusted to design sofftwaie 
applications which access the sensitive API; 

receiving a hash of a software application; 

detemiining if the software application was designed by one of the legisteied software 
10 developers; and 

if the softwaie application was designed by one of the legisteied software developers, 
then generating a digital signature using the hash of the softwaie application, 
wherein 

the digital signatuie may be appended to the softwaie application; and 
IS the mobile device verifies the authenticity of the digital signatuie in order to control 

access to the sensitive API by the softwaie application. 

46. The method of claim 45, wherein the step of generating the digital signatuie is peif oimed by 
a code signing authority. 

20 

47. The method of claim 45, wheiein the step of genemting the digital signatuie is peiformed by 
applying a signature key to the bash of the software application. 
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48. The method of claim 47, wherein the mobile device verifies the authenticity of the digital 
signature by performing the additional steps of; 

providing a conesponding signature key on the mobile device; 
5 calculating the hash of the software application on the mobile device to obtain a 

calculated bash; 

applying the corresponding signature key to the digital aignabue to obtain a recovered 

hash; 

detennining if the digital signature is authentic by compadng the calculated hash with the 
10 recovered hash; and 

if the digital signature is not authentic, then denying the software application access to 
the sensitive APL 



49, A method of restricting access to -plication programming interfaces on a mobile device, 
15 comprising the steps of: 

loading a software application on the mobile device that requires access to one or more 
application programming interface (API); 

deteimining whether or not the software application iacludes an authentic digital 
signature associated with the mobile device; and 
20 if the software application does not include an authentic digital signature associated with 

the mobile device, then denymg the software application access to His one or more APIs. 
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50. The method of claim 49, comprising the additional step of: 

if the software application doesmot include an authentic digital signature associated with 
the mobile device, then purging the software application ficom the mobile device. 

5 51. The method of claim 49, wherein: 

the software application includes a plurality of diptal signatures; and 
the plurality of distal signatures includes digital signatures respectively associated with 
different types of molrile devices. 

10 52. The method of claim 51, wherein each of the plurality of distal signatures is generated by a 
respective corresponding code signing authority. 

53. The method of claim 49, wherein the step of determining whether or not the software 
application includes an authentic digital signature associated with the mobile devioe comprises 
15 the additional steps of: 

determining if the software application includes a digital signature associated with the 
mobile device; and 

if so, then veri^g tiie authenticity of the digital signature. 

20 54. The method of claim 53, wherein the one or more APIs includes one or more APIs classified 
as sensitive, and the method further comprises the steps of, for each sensitive API: 

determining whether or not the software application includes an authentic digital 
signature associated with the sensitive API; and 
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if the software application does not include an authentic digital signature associated with 
the sensitive AH, then denying the software application access to the sensitive API 

55. The method of claim 52, wherein each of the pluraEty of digital signatures is generated by 
5 its corresponding code signing authority by applying a respective private signature key 

associated with the code signing authority to a hash of the software application. 

56. The method of claim 55, wherein the step of determining whether or not the software 
appUcation includes an authentic digital signature associated with the mobUe device comprises 

10 the steps of: 

determining if the software appHcation includes a digital signature associated with the 
mobile device; and 

if so, then verifying the authenticity of the digital signature, 
wherein the step of verifying the authenticity of the digital signature is performed by a method 
15 comprising the steps of: 

storing a public signature key on a mobUe device that corresponds to the private signature 
key associated with the code signing authority which generates the signature associated with the 
mobile device; 

generating a hash of the software application to obtain a generated hash; 
20 applying the public signature key to the digital signature to obtain a recovered hash; and 

comparing the generated hash with the recovered hash. 
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